SREチームの１年間のお仕事を振り返る

#AWS

#働き方

望月政夫

2017.12.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本日、12/22はクラスメソッドの2017年最終営業日です。最終日ということで、筆者の2017年の一年間のお仕事（の一部）を紹介したいと思います。主に、私がいま関わっているprismatixというサービスについての話になります。

prismatixの紹介

prismatixはEC/CRMのためのAPIプラットフォームです。商品・顧客・注文のような、ECに必要な機能をAPIとして提供し、小売業の方々の支援を行っています。

私はSREチームのリーダーとして、同僚のtjinjinと二人でprismatixのインフラ改善・サイト安定化、管理効率化に取り組んでいます。

2017年にやったこと

Elastic Beanstalk DockerからAmazon ECSへの移行

もともと、2017年1月の段階ではこのシステムはElastic Beanstalk Dockerで稼働していました。マイクロサービスの数が増えるに従って、EC2の構成やOSの設定などに深く手を入れたいと思いはじめ、2017年3月頃からECSの検証をはじめました。この移行は想像以上に簡単で、2017年6月にはそのまま本番投入となりました。これはDockerのポータビリティのおかげだと改めて感じました。

ECSに移行したことでコンテナの集約度が上がり、AWS費用的にもかなり削減することができました。

この話は、いつかどこかで20分くらいでまとめて勉強会などで話したいな、と思っています。

デプロイツールの作成

とはいえ、Beanstalkが自動で行ってくれていたデプロイは、ECSではちょっと一手間必要です。巷にはecs-deployなどのデプロイスクリプトがありましたが、プロダクトの性質上、既存スクリプトの流用が難しいと感じていました。

シングルテナントで環境数が多いため、デプロイ対象の設定などはかなり多様化している
将来的にマイクロサービスが増え各サービスの前提が異なっても、共通の操作でデプロイ出来る仕組みが必要
コンテナに設定する環境変数は外部のデータストア(S3等)から埋め込みたい（これは半分思いつき）

既存のツールでは要件にマッチするものを見つけられなかったので、自作することにしました。作成したツールではSystem Manager Parameter Storeにマイクロサービス毎の環境変数を埋め込み、デプロイ時にTaskDefinitionに埋め込む形をとりました。

Datadogの導入

インフラ/アプリケーション的に様々なメトリクスを取得するため、Datadogを導入することにしました。Datadogでは様々なAWSサービスとのIntegrationを提供しており、さらにECSのメトリクス監視用のDatadog agentの設定をドキュメントで公開してくれています。これを参考にECS Clusterの各Container Instance上にDatadog agentを起動し、コンテナやEC2の状態を監視するようにしました。

上述の通り、多数のAWSアカウントにプロダクトを展開しているのですが、Datadogでは複数アカウントのAWS環境の監視も単一のプロジェクトで行えるのが大変気に入っています。

構築業務の省力化

多数のマイクロサービスを多数の環境にデプロイするためには、自動化されたプロビジョニングの方法が必要不可欠です。prismatixでは非常に多数のAWSリソースを用いるのですが、これを全て手動で構築するのは非常に非効率、かつミスが発生しやすいものなので、人力での環境操作を可能な限り排除する必要があります。

prismatixでは環境の構築をCloudFormationやbash/Python/Rubyのスクリプトで自動化し、環境の複製が容易なようにしています。

アプリケーションの改善

アプリケーションを運用していると、アプリケーション処理が遅くなることや、ログが不足していて調査に難航することがあります。そういう時にはSREチームでもアプリケーションコードを修正したりSQLを直したりしてPull Requestを出しています。「インフラチームはアプリケーションに手を出さない」ではなく、「必要だと思ったらやる」という文化で日々仕事をしています。

2017年にやりきれなかったこと

デプロイツールのOSS化

上で上げたデプロイツールですが、一部内部のコードに依存している部分を引っぺがしてOSSとして公開するつもりでした。がそこまでたどり着くことができず...2018年にはGithubに公開してまたブログを書きたいと思います。

AWS Athenaでのログ解析基盤

現在はCloudWatch Logsにアプリケーションのログを流してそれを解析しています。サービスが成長するにつれてログ量が増えてくると、CloudWatch Logsの料金が膨らんできてしまい、対策を考える必要がありました。

CloudWatch Logsへの転送はfluentdを使って実施しており、fluentdでログのS3への退避も行っています。このログをAWS Athenaで解析することで障害時の調査に使えるのではないか、と目論んでいます。

コンセプトの実装までは完了しているのですが、全環境への展開が今年中に完了せず。。これも来年への持ち越しです。

Prometheusの導入

tjinjinが手動して、監視ツールであるPrometheusの導入を進めています。上述の通り既にDatadogを利用しているのですが、開発環境やより細やかな条件でのモニタリングなどに使えるのでは、と思っています。2017年には採用事例もかなり聞くようになってきたので、2018年にはもっと流行るのではないかな、と勝手に思っています。

2018年にやりたいこと

EKSの検討

先日のAWS re:Invent 2017で発表されたElastic Container Service for Kubernetes(EKS)には興味津々です。

【速報】AWSのマネージドKubernetesサービス、Elastic Container Service for Kubernetes(EKS)が発表されました！ #reinvent

現状ECSで動かしていますが、それをEKSに移行すると何か良いことがあるのかな？からの調査ですが、GAになるのを今から非常に待ち望んでいます。

環境構築/更新のより高度な自動化

上で触れたとおり、構築作業は基本的に全てCloudFormationやスクリプトで行っています。単一の作業はこれで自動化されているのですが、環境全体を構築するためにはこういったスクリプトを順番に実行する必要があり、それが手がかかる要因になっています。とはいえ、単純にすべてを連結してシーケンシャルに実行しようとすると、「前のスクリプトが失敗したらリカバリどうするの？」みたいな話になり、ジョブネットのようなものが欲しくなってくるんですよね。

この問題を2018年に解消していきたいと思っています。この課題の解決になるかはわかりませんが、最近はSpinnakerが非常に気になっているので、これも併せて触ってみようかな、と。